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(57) Abstract 

A code translator, constructed similar to a 
compiler, accepts as an input to be translated the 
assembly code written for one architecture (e.g., 
VAX), and produces as an output object code for a 
different machine architecture (e.g., RISC). The in- 
put code is converted into an intermediate lan- 
guage, and a flow graph is constructed. The flow 
graph is referenced by a flow analyzer for recogniz- 
ing certain architecture-specific and calling stand- 
ard-specific coding pratices or idioms that cannot 
be automatically converted, particularly relating to 
stack usage, register usage, condition codes, and 
passing arguments for procedure calls. By tracking 
stack usage within routines, the compiler can dis- 
tinguish up-level stack and return address refer- 
ences from valid local references. Also, it can in- 
form the user of stack misalignment, which has a 
severe performance penalty, and can detect code 
segments where different flow paths may result in 
different stack depths at runtime, which may mdi- A^ m {ne which registers are destroyed by a routine, and generate 

cated a source code error. Register usage ,s l *™ se ^^ "hints" to aid the user in adding an 
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BACKGROUND OF THE INVENTION 

Ttts invent relates . programs for *gha! comparers. - ~ 
lv » code Elation for conve*ion of instmetion code wh.ch was wrmen for one 
computer architecture ro code for a more advanced architecture. 

Con^^ehi^^de^of^basicsuucn^ofaco^ . 
^ ^ of what ctaedy can be performed by code wnnen for 

memorv management funcnons, etc. usuauj. 
pressed as an instruction set, and related elaboration. 

* me Oology used in c— g ^ 
arehhecture. Semiconductor technology has served to make all st ™«^ 

*,«er less costly, smaller, lower in power diss.pat.on. and more 
' 'Zri Z'TSJL^ m the economics and perforce of the comput- 

nLssary. to make coreesponding changes in archnecture ro take 
er hardware, it is nw^*; the CPU data paths 

fun advantage of existing hardware technology. For example, the CPU d*» 
tuu aavamag ^ memory has become 

tave evolved from eItended . A major departure in 

— ; ~rL«d architectures w*. reduced — sets have 
been shown to provide performance advantages. 
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rtsc orocessors are chamcrerized by having a 
Complex msmrcrion set or CISC process ^ory-to- 

JL* instructions wim ~ "^Tlv on, ^ in 

of variable toga, with snnplemsBu VAS « injunction set is 

^ out ^eieng* ranging up to 6o^y^ g 0two ^ 

. primary example of OSC and ^JT^Z J operand specifier is 
opcodes plus from aero to six operand spe^ ^ rd ^ 

to. one byte to many bytes in length. The arm ^ ^ 

up on me addressing mode, -^JETTS- ^ {or « operand. 

byre of rhe operand spectfier descnbes me ad ^ 4, 

w ^ n. opcode defines ute nunrber of 0^-^ ya 

opcode hself is decoded, ^^^tve nor ye, been decoded, 
tnown to the processor because die ^^^^^.^^ type is the use of byte or byte 
mother charaoerisric of pmc^s * refereneK; « is. a 

inctaiing maligned byre references. 

, ™ RISC orocessors are characterized by a smaller 
Reduced insnucnon set or RISC prow ^^^.n. 

nnmberrffcsnuerians^^^ 

^'TJSSK 

of allowing no complex memory sim te ^ssing 

storeoperauons,andmemamasmaUn^b»ofm > ^ „ „ 

m odes, U.. only a few ways of specrfymg P-^ ^ ^ ^ ^ 
only one length, and memory accesses am * rfcrocoding. 
Jucrion execution is of me £j£ _ ^ „ „ 

^ 1 ' ^e^ret I shorr cycle (on average, rince 

CSr^l- — -^cycies, 
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0. m of CISC processors is in writing » 
powerful CISC mictions, memory accessing ^J«£Z ot^oduce 
* mo* wo* King done for eacu Une of code «. of 
code taHng fun advantage of mis). However *»"^" rime, 
source code for * CISC processor is accomphshed ar the ^ 

as pipeUning of unction — * ~ - 

performance fcvels demanded of systems ^e 
. -ad the vast differences in memor> access uiu 

^ccesstve ^ exceptions , sl „wing execution. The 

cvcie rune. produ« «— rf of codc . b ur rhe disadvan- 

advantage of a RISC processor is tnc code to accomplish a 

• .«« is accomplished by each line of code, and the code to 
tage is that less is accompiisn w of V AX code can accomplish the same 

given task is much more lengthy. One line of VAX code 
as many lines of RISC code. 

Wn . . th CPU would always be waiting for the 

memory speed became more u«u« deliver one 

, mnr , f eas ible assuming the memory system is aoie to u 
concents became more teasmie, <i»ui 6 . . we n 

, in each evele Hierarchical memory techniques, as *eu 

instruction and some data in each cycle. m ^ ^ 

« rvrfes orovide these faster memory speeds. Anomci 
as faster access cycles, provide u an(re in relative cost of off-chip vs. 

, , ^ cr vc -Rise choice is the change m relative 
influenced the CISC vs. JU^ caoi^ Construction on 

on-Cup in— ction resuming from -rirec 

chips instead of boards changes rhe econom.es - firs. > pays M. 

J s toP .e enougn ro >e on one C, ^ — ^in rhe 

— > » «* •*« **» f " "T^STL addressing modes as in a 
comparison is *ar adding more ^~»*Z rf ^ eMCUti0 n 
CISC solution compticares (tiros slows down) stages 
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, faction rnieht make the function execute faster than an 
^s, n. ^"° n ^ ons , but it can lengthen the instruction cycle 
equivalent sequence of stmple muS t incxease 

^ tnaking all instructions „ * the instruction 

the overall performance enough to compensate 



execution rate. 



^ T,icr ^rtcwors taking into account these 

the existing software oas operating systems and apphca 

[0 tions programs, build up to & nign product of me best available program* 

toe .te ^vant^ of matog use of the p^ <rf _ ^ f ot 

nuug^.cot^-aute^^c^^ 

T r n architccnire was adopted every m« 
long period of tune. If a wo uld never teach a viable level. This issue 

advance- allowed n, me software base wool ^^taninC 

— 4 * * " te C °^S^du«d on various architectures supposed* 

* — " ^™^LIbly language programs are architecture- 
paroi of applications programs. Assemoiy 



dependent- 



m enters ~^J^£ZL. 

as wen as the cost clSC-rype processors which were the most 

^ and dara structures ^ J^^e and disruption 
^elv used in me pas. ran or fifteen years. Th rpe , ww 

tion s to rewrire me code and data strucnires by hand to ac 
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i_ ^ may no, be Jusdfied. «- - >«" 

ulltaaa ly expected to be achieved would be substannal. 

Code translators am thus needed to ease the task of convening codewrtaen 
for one compmer architecuue to ma, executable on a more 
i purposed a code u—r is to .a* m. as input, 

exeeuuTon one type o, archhecture (e.g.. VAX), and/or one operanng sys«m 
eTvMS). and tTpoduce as an output either executable code (object code) or 

for Z advanced architecture. Ibis is preferably to be done, of 
:„L. with a tninitnutn of operator involvement. ^ 
viator is to detect huen, enor-pn»ducing features of the code, features that 

^ m or^hitecn^e, but which may produce «. in the new envtronmen, 

SUMMARY OF THE INVENTION 

fc accordance with one embodiment of me invention, a code 
eonsrrucred in a manner similar to a compile, and may indeed be 
^2 compiler. The code .anslarot accepts as an input 
Lrce code which is to be <ransla«d. in a manner similar to the from end of any 
^ef The .put code is parsed to de,ermi« its content, with 
JL of dte code identic (separa^d) and corned J- — 
guage. The intermediate language veraon of me code is store 
TfeLd to as a flow graph. The flow graph is referenced by flow analyzer tech 
JT«d op—on routine, before generating object code for the targe 
ZL ^translator is particularly adapted for transUting VAX assembly- 
language inro an advanced RISC architecture. 
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e n<;C architectures into code for a RISC 

architecture, there appear cenain °"^- Spe ^^L piler d«c« 
„• ™-riee S flat cannot be amomarically convened. The comp 

— ^r^-— AVAXproeedure 

fend*. By tracktng stack mage references. 

trp-fcve. stack and »T"^ld. ha, a severe 

•-#«r™ the user of stack misalignment, wnicu u 
In addition, rt can inform the user of where different flow 

-piriaUv it can detect coae scgu«*«« 

performance penalty. Finally, u indicate a source 

, • Ji«i.-.nt crack depths at runtime, wuro 
paths may result in different stacK oc P 



code error. 



records the amount of which the stack pom ^ 
. modifies the return address on the stack 



a co-routine linkage 

. makes an up-level stack reference 
. makes an unaligned stack reference 
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. modifes SP such A« it is no longer longword aUgned 
fc each of these cases, the compiler/translator *■» *- ~" 50 
.pp^ changes to the source »«J^ ^ ^ . Ae 

^ a value was inadvertently left on the stact. 

ta the original source code, where a value was 

Another feature of interest in convening code from one Wecr^e to ^ 
Anotner icw* assembly language frequently 

another is that of register usage. I JL on the ^ 

and restore them before rounne exit, in otn _ d=stroy ^m. 

j . email rantre of instructions winch are Known to ue»u j 
and popped around a small range of ^ 64-bi. RISC 

compiled code will be executing in . envuonmem where many ro 
7Z values, so rhar a 32-bh savefrestore bperadon is no, sufBcrent. 

According in one embodiment of the invention, the compiler tracks 

Taid^user . adding an enu, ^ l^r 
a H-ciaration of routine output registers is requireu » 

rlnot A JZZ or^na. — ~ - * ^ — " ^ 
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ttEisK r hints may also be useful in identifying these. The input register hints may 
afco uncover tags in which code incorrectly uses uninitialized register values. 

For each basic block in the routine being compiled, the compiler tracks 
^chmgis^amreadandt^ byttainsr^onsmtheblock At the same 

unre. it accumutaes the set of registers written for me attire routine. Dag > 
forward MMk through the basic blocks, the compiler computes whtch 
rcgisKK are wrtaen tat not subsequently read, to be reponed as possible omput 
refers of the routine. During backward flow-order walks frontal! etdt potnts of 
.he routine, the compiler computes which registers are read before being wxmen. to 
be reponed as possible input registers. 

When generating code for the routine, the compiler uses the list of registers 
^xtaen to determine which should be saved by routine prologue code. Registers 
which have been explicitly declared as routine output or scratch registers are 
removed from the set. Routine epilogue code is generated to perform the register 



restores- 



According to another feature of one embodiment of the invention, the usage 
of condition codes are tracked. Many computer architectures such as VAX make 
ose of condition codes (overflow, equal to zero, not equal to zero, etc.) generated by 
te ALU and imemally stored for later reference in a conditional branch, for 
«ample. Nearly all VAX instructions modify these condition code bits whtch are 
M of the machine architecture. Other insuuedons test these bits «o detect condt- 
"rions such as overflow or perform conditional branches. In addition, because these 
hns survive Jump-subroutine (JSB) routine invocations, they are sometimes used » 
assembly language as implicit routine parameters or return status codes (.hough tins 
is „o, a recommended coding practice). An advanced RISC archltecmre has no 
condition code bits. in*ead. when a condition is «o be needed, an explicit test » 



SI IRRTITI ITF SHFFT 



WO 92/15939 



PCT/US92/01841 

\ 



9 



0 



, * t?t<?C architecture, the compiler must trac*. c« 

e^s automatic^ grated* ^ ^ condition codes. The transUtor 
wo^te^^necess^tantento gen™^ ^ t parameters or 

rottS , ^a^^- ^r^rtr^viofc^ * — . 

»»» mum values and report « . *e «~ ^ ^ g ^ 

t« instead must be receded. * ■ *° » ~ , 

tion code vaiue se, bv i» calier may ^ a codmg enor. 

«. compiler builds a * ^^J^SE* - — »oc*. 
waKs mis graph in reverse flow order ft» d — »- ^ codcs „ 

up^^rc^en^^n^a^ofw^^^^ 

„■* which condition codes as successor mqumt fe 

cades. »*«^—. ^^T^"jr»d ..hecompilerwill 
^"set. When all instructs . ^ ^ This will 

n^orithe set of condition codes suD reqmred as mput 
connnue aU processors of *e current block. 

-low graph, and the "required" set » non-emprv. the user > 
codes appear to be used as implicit ISB routine outputs. 
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» is possible and Han* that a node will be vished mo« *- °ncedurmg 
backward wa*s. When a node is revisimd. «he confer wdl compare me 
^ .^quired" seragains.th.inuMsetsoredby.he previous wait ^and 
^ « *e averse! if the required codes were previously searched for. 

^ an backward paths have been examined, me compiler checks the basic 
Mock corresponding ,o rhe routine emry node. If *e "inpu," se. is no. empry for 
^nTTuser I informed rharthe refine expecs condidon codes as mpu, and 
that a source code change is required. \ 

, ii.r ™*mn«s are handled. VAX assembly language 
» * «y "P™"* te T " r^rablished by rhe VAX CALLS/- 
xourines rely on the argument list pomBrCAP) established by me 

^mLcrionsm^ton^P-^O""^^ 80 

taverns, resets this difierence wirhour requiring aH to 

* modified in me source code. Tbe argument «sr references are mapped across the 

arehirectures in making the code translation. 

m con.pnar examines all AP-based memory references in me input code to 

VAX; in the target RISC archnecmre. me ^T^T^l. a 
«rister e £ the Argument Information Register (R25). Hence, in mis 

to sixargumenrs are received in registers R16-R21 on m the «rget « 
nrrc. so ma. 4(AP) wffl be compiled to use R16. 8(AP) to use R17. etc. 
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In some cases, the compiler mimics VAX argument lists 
qu adworo tegtstet and sue, -gnmems mm a 

TOs argument list "homing" occurs if me compiler ^ liable 

rnsuK in aliased references to me argument list, any AP references wnn 
result m au*~- Bgumem list 

indices, or any non-longword Signed AP ^ ^ 

VAX code^te compiler generates code to copy arguments from the stack, w ^ re 

isrs If then axe mom than six arguments (requiring mom man R16-R21). me 
^2 ^beyond must he copied » conserve aligned 64* slots on ^ 

^AX, would have heen at 0(FP). Conesponding code to clean me stack after 
the called routine mums is also generated. 

BRIEF DESCRIPTION OF TOE DRAWINGS 

Tne novel feamms helieved characteristic of *e mvennon are se, for* m the 
anoendTclaims Tne invention teelf. however, as well as odier features and ad- 
will he hest understood hy reference » the detailed desermnon of 

^TSL- — — * - * T 

ing drawings, wherein: 

r u «,™ w or code translator functions, according to one 
Figure 1 is a diagram of the compiler or cooe trans 

embc>diment of the invention; 
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Figure 2 is an electrical diagram of a host computer for executing the code transla- 
tor program of Figure 1; 

Figure 3 is a diagram of an example of a line of code translated by the mechanism 
of Figures 1 and 2; 

Figure 4 is a diagram of the data structure of a mple created m me code translator 
of Figure 1; 

Figure 5 is a more detailed diagram of the compiler front end in the translator of 
Figure 1; 

Fogure 6 is a listing of a small example of code illustrating the basic blocks or 
nodes of the code; 

Figure 7 is a flow graph of the program expressed in the code of Figure 6; 

Figure 8 is a listing of another example of code used as the basis for the example of 
Appendix A; 

Figure 9 is a flow graph of the program expressed in the code of Figure 8; 

Figure 10 is a logic flow chart of a procedure referred to as Build_Flow_Graph, 
used in the method of the invention, according to one embodiment; 

Figure 11 is a logic flow chart of a procedure referred to as Analyze.How.Graph, 
used in the method of the invention, according to one embodiment; 
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Figure 12 is a logic flow chart of a procedure referred to as Tra- 
vcrsc_Graph_Forward, used in the method of the invention, according to one 
embodiment; 

Figure 13 is a logic flow chart of a procedure referred to as Tra- 
vcrse_Graph_B ackward, used in the method of the invention, according to one 
embodiment; 

Figures 14a and 14b are a logic flow chart of a procedure referred to as 
Process_Forward_Node, used in the method of the invention, according to one 
embodiment; 

Figure 15 is a logic flow chart of a procedure referred to as Pro- 
cess_Backward_Node, used in the method of the invention, according to one 
embodiment; 

Figure 16 is a logic flow chart of a procedure used for mapping argument list 
references in translating code to another machine architecture, used in the method of 
one feature of the invention, according to one embodiment. 



DETAILED DESCRIPTION OF SPECIFIC EMBODIMENT 

Referring to Figure 1, the code translator or interpreter 10 according to one 
embodiment of the invention resembles a compiler, and includes a portable operat- 
ing system interface referred to as the shell 11, as well as a from end for converting 
the code and a back end, with optimizer and code generator, as is the usual practice. 
The shell 11 may be portable in that can be adapted to function with any of several 
operating systems such as VAX/VMS, Unix, etc., executing on the host computer 
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12. The shell 11 operates under this host operating system 13 executing on a host 
computing system 12 of various architectures, as seen in Figure 2, typically includ- 
ing a CPU 14 coupled to a main memory 15 by a system bus 16, and coupled to 
disk storage 17 by an I/O controller 18. The shell 11 and other elements are 
5 combined with a front end converter 20 to create a translator or "compiler" for 

converting code in a first language, e.g., VAX/VMS assembly language, into object 
code for a different target architecture, e.g., and advanced 64-bit RISC architecture. 

The front end converter 20 is the only component of the translator 10 which 
understands the input language being translated (compiled). This input language is 

10 that used in the file or files (module or modules) 21 which define the input of the 

translator. The front end converter 20 performs a number of functions. First, it 
calls the shell 1 1 to obtain command line information entered by the user (person 
operating the host computer 12 of Figure 2). Second, the front end 20 calls the 
shell 11 to control the listing file, write diagnostic messages, and the like, as is 

15 usual for compilers. Third, the front end 20 does lexical, syntactic, and semantic 

analysis to translate the code of the input file 21 to a language-independent internal 
representation used for the interface between the front end and the back end. 
Fourth, the front end converter 20 invokes the back end (remaining parts of the 
translator) to generate object code modules 23 from the information in the internal 

20 representation. Not included in the translator 10 of Fig. 1 is a linker 24 which links 

the object code modules or images 23 (with runtime library, etc.) to form an 
executable image to run on the target machine 25. 

The target machine 25 for which the back end 12 of the compiler creates 
code is a computer (generally of the form of Figure 2) of some specific architecture, 
: - i.C it has a register set of some specific number and data width, the logic executes 

a specific insmiction set, specific addressing modes are available, etc. Examples are 
(1) a RISC type of architecture based upon the 32-bit RISC chip available from 
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MIPS, Inc., as part number R2000 or R3000 and described by Lane in "MIPS 
R2000 RISC Architecture", Printice-Hall, 1987, and (2) an advanced RISC architec- 
ture with 64-bit registers as described in copending application Serial No. 547,589, 
filed June 29, 1990. Various other architectures could be likewise accommodated, 
employing features of the invention. 

In general, the front end convener 20 need not consider the architecture of 
the target machine 25 upon which the object code 23 will be executed, when the 
front end 20 is translating from source code 15 to the internal representation, since 
the internal representation is independent of the target machine 25 architecture. 

The back end of the translator 10 functions like a compiler to translate the 
internal representation constructed by the front end 20 into target system object code 
23. To this end, the back end performs the basic functions of optimization 26, 
storage and register allocation 27, and code generation and object file emission 28. 
The optimization function is performed on the code when it is in its internal 
representation. 

When the user (that is, a user of the computer system of Figure 2, where the 
computer system is executing the operating system 13) invokes the translator of 
Figure 1, the shell 11 receives control The shell 11 invokes the front end converter 
20 to compile an input stream from input module 21 into an object file 23; the front 
end 20 invokes the back end to produce each object module within the object file 
23. 

The front end 20 parses the input code 21 and generates an intermediate 
language version of me program expressed in the input code. This intermediate 
language version is stored in intermediate language tables 30 (including a symbol 
table), which are updated and rearranged by the stages of the compile functions as 
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A tuple is an expression which computer programming language performs flne 

in a high level computer language as 
I = J+1 

would appear in the assembly-language input file as 
ADDL3 #1 JJ 

add T to fee conrems of memory location J and piace «he result ^ 
location L This code will be eventually translated into object code for a RISC 
^ which does only regisrer-to-regis^ anthmeuc. and only regisrer-to-memory 
or memory-to-register stores and loads, so h wm appear as 

LOAD Rn J; Load memory location J to Register N 
ADD Rir,#l; Add constant 1 to Register N 
STORE Rni Store Register N to memory location I 
to inrennediare language, however, the code is in a more elemental (and generic) 
form than even RISC assembly, and would include five tuples, these berng number 
SI. $2. S3. $4 and S5 in Figure 3. This way of expressing the code in E. mctades a 
mpte $2 which is a fetch represented by an hem 31. with the object of the fernh 
Jug a reference to symbol J, shown in tuple «. The next tuple is a hteraL «em 
32 making reference to the constant "l." The nexr tuple, item 33. is symbol 
reference to T. which will befee target of the addition operator. The last tuple rs 
an Add^tem 34, which mates reference to fee sorirce tuples S3 and S3, and to the 
destination tuple $4. The expression may also be expressed as a logic nee as seen 
in Hgute 3. where the tuples are identified by fee same reference nnmerals. 

A tuple (also referred to as an n-tuple), then, is the elemental expression of a 
computer program, and in the tarn used in mis invention is a data smucmre 35 
whil JlinTfeast fee elements se, ferfe in Ftgure 4. including (1) an orator 
field 36, e.g.. Fetch. Store, Add. etc.. (2) a locator 37 for defining where m fee 
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input module 21 me input-code equivalent » the tuple is located. (3) operand 
poimers 38 to other tuples, to tart nodes or symbol nodes, such as the pomters to 
iand #1 utp.es $1 and S2 in Figure 3. A tuple also has attribute fields 39 whrch 
may include, for example. Label. Conditional Branch. Argument (for Cafls). or 
SymRef (a symbol in the symbol ttble). The tuple has a number field 40. repre- 
senting the order of this tuple in the block. 

Referring to Figure 4, the from end convener 20 parses the input code 21 to 
identify tuples and to build an intermediaie language mple stream 41 and assorted 
symbol table 42. The ne» step is performed by a flow analyzer 43 is to scan the 
«fc soeam and identify basic blocks of code, called nodes. A block of code ts 
defined to be a sequence of mples with no entry or exit between the first and last 

Usually a block stans wim a taoel or routine entry and ends with a branch to 
!L« labeL A task of the convener 20 and flow analyzer 43 in me front end rs to 
parse the input code 21 and identify me tuples and blocks (nodes), which of course 
Luires the from end to be language specific. The tuple data structure 35 contanrs 
fields 44 and 45 mat say whether or not this tuple is the beginning of a block, or 
the end of a block. 

A flow graph 46 is generated by the flow analyzer 43 in the front end. The 
flow graph 46 consists of nodes, which are me basic blocks of me program, and 
edge^which represent the flow between node, The flow graph is bulk by process- 
ing me mples 35 (mtermediate bmguage) creaed by the front end convener 20 of 
the compiler. 

The process of building me flow graph 46 by the flow analyzer 43 includes 
waiking me mples sequentially for each program section. Referring » an example 
of code as seen in Figure 6. me flow analyzer 43 adds mples to the current flow 
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node until one of the following is encountered, thus defining when the previous 
node ends and a new node begins: 

(a) a label - branches to die label LAB 1 will result in an edge being created 
to this node; hence, the label LABI is the first raple in the new node Node-3, and it 

5 creates the edge ending Node-2; 

(b) a routine entry point, in this case JSB_entry (the first tuple in Node-1, 
which is treated like a label for purposes of flow - however, die routine entry has an 
additional symbol table entry Routl identifying it as a routine; 

(c) a branch instruction - the branch BEQL ends the preceding block. Node- 
10 i, and the next instruction CLRL begins a new block, Node-2; 

(d) a return instruction, RSB, which is treated like a branch instruction which 
branches to a special routine exit node; thus RSB ends Node-3, which is only one 
tuple in length. 

A branch instruction such as the BEQL of Figure 6 also results in an edge 
15 being created, linking the node (Node-1) containing the branch to the node (Node-3) 

containing the label which is the branch destination (LAB 1). If the branch is 
. conditional, as here, an edge to the immediately following node (Node-2) will also 
be created, since flow may "fall through" to it. Indeed, an edge is a bidirectional 
link; the flow needs to be traceable in bom forward and backward directions. 

Accordingly, the intermediate language used in the code translator of Figure 
1 is expressed in the tuple stream 41 and a symbol table 42, along with the flow 
graph 46. The primitive concept is the tuple, and the intermediate language flow 
graph 46 is made up to link the tuples into node or blocks representing the opera- 
tions to be executed, each tuple 35 having a data structure as in Figure 4. These 
25 tuples 35 within nodes are tied together by pointers which represent various 

relations. The most important relations are the operator-operand relation (a pointer 
38 from an operator to each of its operands) and the linear ordering represented as a 



20 



SUBSTITUTE SHEET 



WO 92/15939 



PCT/US92/01841 



19 



tuple number field 51 on all the tuples in each basic block of the intennediate 
language flow graph 46; the order of the tuples within a node provides the execu- 
tion order. 

As mentioned in reference to Figure 4, each tuple 35 has various fields, 

including the following: 

(a) Generic operator 36 - identifying the general operation performed by the 

tuple, e.g., ADD, FETCH, etc. 

(b) Operator type 52 - a data type which, normally, determines the specific 
operation performed by the tuple. The operator data type is primarily of interest 
only on data storage tuples. Instruction tuples arc by definition self-contained, and 
will not be referenced in later instructions; hence, their data type is null. 

(c) Result type 53- the data type of the value computed by this tuple. This 
is set only on data reference tuples, e.g., those that can be used as operands of other 
tuples. 

(d) Operands 38 - an array of pointers to the operands of this tuple. The 
number of operands is detennined by the generic operator. Each operand pointer 38 
points to another intermediate language tuple node, or, in some cases, to a symbol 
or literal node in the symbol table as in tuples $1 and $2 of Figure 3. 

(e) Next/Prev tuple 54 and 55 - pointers to the next and previous tuples in a 
doubly-linked list of tuples. The next tuple order is the implicit order of evaluation. 

(f) Locator 37 - the textual location in the input module 21, Le., in the 
program source of the token or tokens which are compiled in this tuple. The 
locator is used in constructing error messages, source correlation tables, etc. 

(g) Use count 56 - mis field is set by the analyzer to the number of referenc- 
es made in data reference tuples. 

Some types of tuples have additional fields, known as attributes 39. Instanc 
es of attributes in the code translator in an embodiment of Figure 1 include: 
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(a) Reference .mibutes, wnieh poim «o nodes in the symbol table 42. Tltese 
are always present m LITREF, SYMREF, LABEL and entry point tuples, ^"^^f 
ro hrera! nodes, symbol nodes, label nodes, and enrxy nodes, respectively A pomter 

, . „„ r 4n a COMP OP tuple. These symbol table 

to a literal node may also be present in a tuivir_ur ^ 

entry types air discussed in additional detail below. 

(b) Instruction attributes, which are VAX instruction type constants. These 
ate present in INSTR (instruction) and CONDBR (conditional branch) tuples, and 
farther specify the instruction or branch operation. 

(c) Register attributes, which are simply register numbers ^speofied tn 

REGREF (register reference) tuples. 

Other additional private fields may be mtroduced mto me mple structums b^ 
the analyzer or code generator; these include: " 

(a) Condidon code flags in field 57 on INSTR and CONDBR tuples. These 
axe used by the flow analyzer 43 to indicate that the code generator 28 must 
instantiate one or more of the VAX condition code values for an instruction. 

(b) A register-loaded field 58 for SYMREF, MEMREF, IDXREF and 
FETCH tuples, used within the code generator 28 to allow re-use of addresses or 
values already loaded to registers. 

The flow graph 46 is a major component of the intermedial representation, 
and is consoled and used by me flow analyzer 43. men later traversed by *e 
eynntet 26, the aorage allocator 27 and code generator 28. The tuples 35 for a 

routine or program (or input module 2!) are in * 
by pointers 38. 54. 55. and having blocks or nodes defined by fields 48. 49 Tta_ . 
fiow^ph 46 identifies me nodes or blocks by poimers to dte beginmng and endmg 
tuples of the ruple stream. Since routines, labels, etc, will have entries » me 
symbol table 42. the symbol table is me reference point for .racing me program. 
feding dte blocks and their ordering. The flow graph of the code of Figure 6 may 
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be illustrated as in Figure 7. where it is seen that there are two paths from Node-1, 
that is, to Node-3 via Node-2 if the conditional branch fails, or directly to Node-3 if 
the branch is taken. 

A routine such as that of Figure 7 has an entry or node 59 in the symbol 
table 42 as seen in Figure 5 which includes a pointer 60 to the flow node 61 in the 
flow graph 46, and this node 61 includes pointers 62 and 63 to the beginning and 
ending tuples 35 of the tuples stream 41, Each flow node 61 also has a number of 
other fields, e.g., for stack usage, register usage and condition code usage, as will 
be described. 

Once a pass over the tuples by the flow analyzer 43 has created the flow 
graph 46, the flow for each routine can be walked by the flow analyzer 43 for 
computing the stack, register, and condition code information of interest for certain 
features of the invention. 

A pass is made by the flow analyzer 43 through each routine in the module 
21 as represented in intermediate language as illustrated in Figure 5. The routine 
node 59 in the symbol table 42 points to the flow node 61 for the entry point of the 
routine. The flow graph 46 is recursively traversed starting at this node; first, the 
tuples 35 of a node as referenced in the tuple stream 41 will be walked looking for 
constructs described below. Then, the graph traversal routine is called for each of 
its successors (nodes 61 linked by a forward edge) which has not already been 
visited. The recursive walk ends at nodes which have only routine exit nodes as 
successors. 

The tuples 35 of each node 61 are scanned booking for the following: 
(a) Register references - if the reference is a "read" reference, and the 
register has not yet been written in the current node, it is recorded as part of the 
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node 61 as an "input register" to the current node, in a field 64 for input registers 
If it has been written, it is removed from the "output register" set, i.e., from a field 

65 for output registers. 

If it is a ' W reference, it is added to the "output register set of field 65. 

and the "written register" set of field 66 for the current node 61. 

The "output register" set of field 65 is passed on to each of die successor 
nodes 61 visited. Then, when the flow graph 46 walk completes, this set of field 65 
represents the registers which are written but not subsequently read in the routine. 
This set is reported to the user in a "hint" message, as possible output registers of 
the routine. The user may use this information to add the correct OUTPUT register 
clause to the routine entry point declaration. 

(b) Stack references and modifications - modificarioiis to th* stack niay be 
the result of explicit instructions, such as PUSH/POP, ADD, etc., or due to the 
VAX addressing mode used, such as (SP*, which implicitly pops the stack pointer. 

At the end of the tuples 35 for the current node 61, the net change to SP due 
to me tuples in this node is stored in a field 67 in the flow node. The total depth 
thus far in the routine flow is also computed. This is passed to the node processing 
routine with each recursive call, and stored in me node in a field 68. 

Thus, at every point during this walk, the compiler has available the total 
stack change since routine entry. This allows it to detect code which: 

(i) reads the return address from the stack 

(ii) modifies the return address on the stack 

(iii) removes the return address from the stack 

(iv) issues a jump-subroutine JSB procedure call through the return 
address to implement a co-routine linkage 

(v) makes an up-level stack reference 

(vi) makes an unaligned stack reference 

(vi) modifies SP such that it is no longer longword aligned 
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These arc all flagged with specific errors. The first five are machine 
architecture and calling standard-specific coding practices which must be changed 
manually in the source code. The latter two are flagged due to the performance 
penalties of unaligned stack references. 

As mentioned above, successor nodes 61 in the flow graph 46 which are 
already marked "visited" in a field 69 are not re-visited; however, the flow analyzer 
43 checks the initial stack depth stored with the node in field 68. If that depth is 
different than the total depth at the end of the current node 61, me compiler reports 
a message indicating that this point in the code can be reached with different stack 
depths. This may indicate a source code error, where the stack was not correctly 
• adjusted by the user on some code path. A simplified example of this might be: 



15 



pushl 
beql 



pushl 



rl 

labl 



r2 



•.instructions which do not modify SP 
; instructions which do not modify SP 



20 



25 



30 



labl: 



popl 
rsb 



r2 



; This point may be reached with 1 
; or 2 new lohgwords on the stack. 
; In this case, it is probably an 
; error, because the RSB instruction 
; expects the return address 
; to be on top of the stack. 



The flow analyzer 43 the makes a second pass through each routine in the 
module. This time, the walk is in reverse flow order, starting at the routine exit 
node and walking backward through all paths back to the routine entry point. This 
is also a recursive graph walk, using the edges which link each node 6 1 to its 
predecessors. This time, nodes 61 may be revisited multiple times. 
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^ 35 of each no* 6! « seined in ^ o^. f « *c 

following: ^ ,_ c p or example, condi- 

(a) instructions wui* read the VAX «^ m ^ 

^ ^ch res^c^. A « o, which co^uon 

,. reqnired . M recorded in . field 70 is updared. For example, when 

^ to Z «. wfll be added » ~ ^ „ to to "reared" 

Wh^onswtachsertheVAXCCswto 

^^ a ^ 5 TZ^^offieldTO. This 
to miction mple 35, and ir is removed fiom * ■ value 

flag 57 in the Tuple tells the code — » — CC 
of fl» condition code for this fcstn.cuon.Tms allows** P 

— - •* — tTSSl or » 70 is no, empty when - 
(C ) JSB instmcuons. E the requneo se ^ 

JSB fcaxuoion is eneoumered, the source code as wntten reh« on ^ 
to JSB raxge, tontine, and sull imac, npon rerun, /-"^ . 

v advanced MSC architectures, for example, as tney 

harfwaie bus on some advancea _ 

VAX, this architecture specific coding practice must be changed 
message is generated. 

^^canmpmcess.node-sprede-ssm 

- aKrtV . If the node is encountered later in anouira u 
processed as above, it we now 

• a« « a subset of the set previously stored, tne nooc ^ 
but the "required set is a suosei «. r •'required" set 

the CC flag is set on the correct instruction. 

Twedecessor, the current node's "input 
Also at each call to process a node s preoecess , 

j • ru„ forward walk) is passed. The input 
register" set of field 64 (computed in the forward wax*, 
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regisl er" set of field 64. for the pressor is then updamd - mclude *o* 
inTpassed set which are no, in its own regisKrs" set of field 66. As a 

Ll, L reg*er" se, for a node will ^^"^Tw^ 
tiiis node or any of hs successor — ""^^^t^— ■ 
for each node, the node's "written registers set of field 66 is added to 

set for the current routine. 

After all reverse paths through » routine have heen processed 
information stored in the flow node 61 for the routine emty point is examined. H 
Z "reuuhed" CC set of field 70 is not empty, it implies mat the conespondmg 
ironcodesame^edasinputmmismutine. ■ 

^Litecmms and impossible on omers. (Ibis may 

coding enor, ramer man an huentiohal inKrfacc.) THe pamoular CCs re^d « 
Lpu* are reported to me usex is me primou. If me "input register" set «d» 

message • possible input registers to me xourine. These registers can then be 
XTo me entry point declaration as input rngis**. (Again, mis may also dome, 
a coding error, where an uninitialized register is inadvertently used.) 

The "wrtaen" se. of field 66 for the routine is used in conjunction wim the 
OUTPUT tegister declarations for me routine, to determine which agisters the 

. The original values of these modified 

compiler must generate code to save, ine ongma. 

regLs may be saved in the source code, using, for example, FUSHL and POPL 
Actions. However, these insuuetions wfll only save me low 32-bts of ti* 
^rvalue. Since me code wfll be executing in a 64*, en— , decode is 
J£ general for the advanced 64-Wt RISC archheemte me ^ 
gene!! 64-bi. tegister saves in routine prologue code, and restore them in rouune 
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epilogue code. The compiler saves those in me "written set" which are not declared 
to be OUTPUT (or SCRATCH) registers. (ROA 2) 



10 



15 



20 



25 



The following program is used to illustrate these concepts: 

Test: -jsb_entry 

pushl *0 
beql lab2 
addB rl, r2, -<sp) 

blss labl 
movl (sp)+, r3 

brb lab2 ^ 

labl: addI2 #4, sp 

lab2: popl r5 

rsb 

This same program is also shown in Figure 8 , where it is seen that the tuples 
are numbered $22 to $31. and the nodes are numbered Node-4 to Node-9. The 
flow of the nodes for this program is seen in Figure 9. For this program, the output 
of the front end converter 20 is shown in Appendix A. showing how the program is 
represented as the tuples $22-$31 in the intermediate language. The numbers such 
as 1725024 are the byte addresses of the data location for the present part of a 
tuple, the previous part and the next part, so the data structure of Figure 4 for a 
tuple 35 may be found in memory, and the ordered sequence of tuples is traceable. 
Also it is seen that the operands (fields 38 of Figure 4) are identified by pointers to 
the actual memory location of the specification of these elements. Next, the flow 
analyzer 43 output is given in Appendix B, showing the flow nodes and their 
linkages. Note mat the tuples are re-ordered somewhat. The output code generated 
for this program as a result is given in Appendix C. 

In Appendix D , a listing is given for a different program (not that of Figure 
6) showing some of the compiler messages mentioned above. This listing is printed 
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out by .he facility ordinarily ta • «^«« fOT P™<^ » sonree ^ 

listing for use in error checking and correction. 

Referring to Figures 10-15, logic flow chans are illustrated which represent a 
view of the flow analysis involved in methods having features of the invenuor, 
■me calling structure is summarized in the following paragraphs. 

me procedure referred «o as Bufld.Flow.Greph, illustrated in Kgure 10. is 
called on« per compilation, and functions to build d of the routine flow graphs for 
the entire module being compiled. 

The procedure referred to as Aualyze.Row.Oraph. illustrated in Figure 11. 
is cWafter Btrild>ow_Graph, also once per compile, and funcuons to 
perform tte analysis on all rhe routines in the module. 

a is called by Aruuyze_Flow_G»ph. and Mf caDs Process.Forward^ode of 
J! Ha, to process tire tuples of the current node in forward order. and*en~Hs 
JTreeursively for each successor of tire currem node which has not already been 



visited. 



Theproce4«rere^«»«Treve«_Gr^^^ffl»^taJ'^ 
!3. is .tailed by Analyze.Flow.Greph. and Wt caUs Process.Baclcward.Node of 
plure 15. to P»«ss tite tuples of the current node in reverse order, anddten can, 
aTrecunive* for each predecessor of me extent node, uniess it has beer, vrsrred 
Z Z register and condition code informal stored in it indicare tiret a re-v«« ts 



not necessary. 
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The procedwe refened » - Ftocess.Forw^d.Node. ***** lh Kg«e 
14a . 14b is Alined, and funcrions ro sinrp* wait dre tup.es » f otwart I order. 

, . _ « process Backward.Kode, illustrated in Figure 

The procedure referred ro as nocess_i»"- - 
IS. is setf.coBr.ined, end functions «o sh^ walk .he tuples rn reverse order. 

The "pseudo-variables" used in die Dow chairs of Figures IMS wiD be 
described, before describing rhe flow charts in derail. The pseudo-vanahies « 

^ CCS" «e.»ese. of condition codes which are ""^"««^ 
flTn'ode. Tharis.son^h^u^eid.e.urddsnodeorone of u.su^ 
1 ^ *ese condition codes, and rhe tasrructions which se, rhenr precede 

*" "tpu, regs" or inpu, regis- (field 64) - for a flow node, "inpur.regs" 
m » of'regisrers which are read in this node or one of its successors. 
^totasn^^wnrehnod^regis^P^^^^ 

"Ourpur regs" or ourpu, regisrers (field 65) - for a flow node Output. 
«gs" ate tire se. of regi*ets which are wrinen in dtis node or oneofus 

- - subset tead by ^ 
"Wrinen regs" or wrinen registers (field 66) - for a now none. 

en rugs" are tire" set of registets which m wrinen roindns node itself. 

CCS" or required condirion codes (fie* 70) -a. each po»r d^ng 
^watd'flow analysis, ore ser of condition codes which are by son* 
Xrenrinsntrcdon. Tney are "requhod" because sotne prevtous u*ru«ron 



must set them. 
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or squired ***** TO - -* 
qU ent h*r»cuon. which have no, ye, heen wrtaen by any ms*ucuons. 
„« « for me Wed-CCs" and W 

«. ••Pw.vious" means earlier m the normal rouunc « 
processing pass. Previous means ..previous" must be 

is being processed backward, so reference to "subsequent and pre 

clearly kept in mind. \ 

Refening now the Figure 10. when Build_Flow_.Graph is invoked the 
Refemngno eMm ined. and the decision point 

selected program section, i*.. tuple sneam «. _ ^ procedure is 

This next ruble is examined to see tf it is a ia . . g4< 

™, R3 If so then the current node is ended at the previous tuple, at item 
pomt 83. If so, then me g ^ which control returns to 

this tuple is noted as starung a new node, at item 85, .» 
th edecisionpomt80viapath86. *«^^^^^ 
be a label or entry point, it is examined* pomt 87 m see if i ^ 
branch or return tuple. If so, the current node is ended ^ 
v • rr »nd the next wple is noted as starting a new node, at item 8*. a 
by item 88, and the next tup • ■ node . M Reared by 

edge is created from the current node - to the g0 ^ path 86 . If, at 

u ™ on after which control returns to the decision point *v via P 
the netn 90 which ^ m bn nch or a 

decis.on pomt 87. me tuple m M ' ^ 

r - r, r r ^ - - — — - 
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go via pad, g6. If. « decision point 9!. a conditions! branch was no. found, 
then control returns to point 80. 

Referring to Figure 11. me precede Anaivae.Fiow.aaph be*ns by, ^ting 
„ead of the routine iis, for the moduie being processed, as i^ -» 
,00. Then, die list is checked to see if there are more routines in tite ^^^^^^ 
^on point 101. If so. then tite procedure ^.Grap^F^^ 
the ne* routine, as indices by the item 102; the Iraverse.Graph.Forw^ . 
^cussed below * reference to Figure 12. If no, the* agam 
^ iis. is fetched, at hem 103. and again a check is made a. dec*™ pom. 104 
of whetontem am mom routines in me module. If yes. then tire Tra- 

Graph.Backward procedum is called for the next routine, as mdmamd by tite 
^Tos of the flow chan. passing empty Required^" and "Requtmd-regs - As 
Mcamd by die imm 106. die -Ompu.^egs" value mtumed by Tra- 

^ Graph Backward is stomd as output registers for the routine. If no is tire 
^1 tiLsion poin, 104. .hen again the head of tire routine lis. for me module ts 
fetched, a item 107, and a test is made » see if there are more ro, «. imj 

at point 108. If not, comrol remms . tite caliing procedum at pom. 109. tf 
T the flow node at head of routine is fetched at hem 110. and this data is exam- 

decision poinrs 111, 112 and 113 .o see if die »Input-regs». "Omput-mgs 
md Input-CCs" am non-zero. Each of these showing non-aero resuhs . a report^ 
hin. 7 hems 114, 115 or 116 as indicamd. This is done for each flow node a, head 
of each routine, and after me last rounne control returns at pom. 109- 

Refening to Figure 12, tite Traverse.Graph_Forward routine, called from 
iBm 102 of Figure 11. begins at item 120 by calling tite Process.Forward.Node 
procedum of Figure 14a. for this node. After return from urn Pro- 
LjForwardJ.-ode call, for each node, a check is made at deoston pomt 1.1 » 
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sec if .here are any successor node, !f „«. connol returns » hem 102 of F^uxe 
U i point 122. If so. informal — accessor node is ft** « » 
P3 and checked «o see if it has almady been visited « decision pour. 124. If 
^ d y vishod, dun at decision point 125 me initial suck depth of su^ ntrte 
(isdj b comp^ed ,o a vah* of me final suck deprh of me cun^n node (MJ. tf 
2 1 eqL then conuo, returns . «. hen. 1 21 via pad, 126. *J-- 
127 repons a "run-time suck dtferenee" message, indicating ma. tins code pom, 
can he Cached with difiemm stack depms. If a, point 124 me successor node. 
Lnd no, puviousiy visited, me hem 128 is enured where me inrua! suck a*h of 

plus 4e toial suck change in me current node. Then, me Traverse.urap _ 
vmxim is caBed for me successor node. « hem 129, Remm from Tra- 
verse.^faphiorward passes connol back » the ppim 121. checking for any 
successor nodes. 

The Tmverse.Graph.B.^rd procedure fflustraud in Hgure 13 hegins by 
calling me Process.Backward.Node pro*duu « hem 130. passing Requrred-CCs 
„ a paramour. Upon return from Process.Backwd.Node, the hem 131 n 
enuud; m hem 131 the opeution is » add regisurs which are in "Requnud-regs 
«,« are not in the "Wntun-regs" set f or me curren, node) m me ~ 
la— I node. Next, « decision poin. 132. a check is nude m see ,f there a« 
any predecessor node, If not. me coruro. temms ,o me caU Tuverse.Graph.Back 
W L point, whh "Ou^u.-regs" as a parameter, via poin, 133. If so,mfomunon for 
A. predecessor node is fetched « hem 134. and a check is made a, pom. 135 o 
1L the predecessor node has heen vished aheady. If aheady vtsued. a check ,s 
^ a. poiTno of whether d. '*e,uhed-CCs" or -Roquired-regs sou are 
afferent dus vis* if no, comrol returns .o point 132 to see if ^ ^ 

ward for the predecessor node, passing the Input-regs set an p 
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_ ,<»r>m^reirs"whicharenothithe"lnput-regs"or 
^ nMets . T*e returned <^-J_~ ^ ^ ^ « ten 138- 
"Wrirten-regs" sec added to the Omput-regs setfor ^ node , 

Co^ol is returned to the point 132 to deremnne rf there are any p 

« to Hgures 14, and * - *-SSS!SSV-' 

procedure, nem 120 oi figure „t~r reference. If so, then 

w ^ is checked a point 142 to see if » is a register reier 

the next tuple ts checkea pu 144 „ see if it is a read or write reference. 

rhe tuple is checked « ponus 143and , 140 via 

ff neuher a read reference nor a TOK re^.»^^^ oseeif 

^H, --^-^^t^^^put-re.s-setat 

140 via path 145. 

• \x> rfFieure 14a it is found that the tuple is not a register 
- P- " 2 rf chcck begiimi n g point 151 of Figure 14b. 

reference, then flow goes » the -* * ^ ^ sp modifica . 

«ion,andifsoures^pornterSPetange^ ^^,54. If 

_ i« ofrer which control xs rctuinca to inc jjuua 
node, at ttetn 153. .ter i, is cheeked a. point 155 to see 

"* ^ hr^rererence wTLt fess than *. where ot^t here indicares 
if it is a stack pomter reference wtth ^ ^ tat to .he routine flow). If so 
(ofiset specified in »p»e plus the total « ^ ^ path 154 . 

. -uplevel stack reference" error tsrepon* . — 15 ^ p^ reference 
, no, dten the tuple is checked at P-^~< 158 „ see if it is a W 
with offset equal to *; if so the tuple is checked at po 
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, ••nfflim address modificanon" enor is reported 
^ce. and if a ™ «— - ■ "T**^ ^ refe rence" error is 
„ hern 159. bu, if »« a — ^Teidrer case. A negadve result 

reported « item 1« before xeturrnngvra pa* 154» ^ 

--^-^.^^tTre^^KSB^^ 

RSBiBStiuction.acheckisreaoe ^ md „„» -.tenure retain address on 
una! are* value is greater than -* * *°» ^ 164 „ 

j ;*-»m 163 but if not then a ence* « 
«*■ error is reporred . <~ ^bu ^ is less rhan in wbich 

«e if the anient stack offset pted«imuai if the tuple is not an RSB 

case . -npreve. return" «or is repone^ ^ po». £ " JSB 

aack poimer baaed location, wnh «*-**»-" r ^ ored « ittm 168. If 

^ TO * " » « » POS-, dte stack is not 

none of the «as at pomts 152. 155, 157 ^ pah 154. 

involved, and conu^l P^ses back to *e pomt 140 of Rgore 

removed from the Kequucu , - , rondilion codes which were required must 
C^ro««r*^t££r.,. represent an h^onwnich 
te reaUzed foi ,1ns *J w , ^ ^ m where «he tuple is 

s«s condition codes, then control passes* cod es. If so. 

checked to see if it represents an -—T^ ^ t0 te quired- 
^ ,he condition codes which the -»~»"^~ which eith er 

nA Tf the tuple does not represent an in*u 
CCs" set at item 174. u tnc »i» 



15 



25 
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sets or reads condition codes, then it is checked at point 178 to see if it represents a 
jump-subroutine JSB instruction, and if so then it is checked at point 179 to see if 
the "Required-CCs" set is empty and if not empty then a "Condition code required 
after JSB" error is reported at item 180. If the test at point 179 is positive, Le., the 
"Required-CCs" set is empty, control returns via path 181 to the point 170. 
Likewise, if the tuple does not satisfy any of the tests of decision points 173, 176 or 
178, control returns via path 181 to see if there are more tuples. 

According to another feature of the invention, argument list references are 
mapped across the architectures in making the code translation in the system of 
Figure 1. In translating code to a different machine architecture it is typically the 
case that the way argument list references are handled is different. VAX assembly 
language routines rely on the argument list pointer (AP) established by the VAX 
CALLS/CALLG instructions to refer to routine parameters. Referring to the 
following example of VAX code: 

.entry routl A M<R2> 



labl 



tstl (AP) 

beql labl 

movl 4(AP),R0 

movl 8(AP),R2 



This routine routl is called by, for example: 



pushl#l 
pushl#5 
calls#2joutl 
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The stack thus has the literal #2 (number of arguments to be passed) at top-of-stack, 
and literals #1 and #5 in the next two longwords of the stack. In referencing these 
via the AP registerestablished by the VAX hardware for the CALLS instruction, the 
code with the two movl instructions moves the first two longwords from the stack 
to RO and R2. 

In contrast, on an advanced 64-bit RISC machine, there is no architected 

argument list pointer (AP). and the calling standard dictates that parameters are 

passed in registers, or. if necessary, on top of the stack. A RISC machine has a 

large number of registers, e.g., thirry-two 64-bit registers, and these are used in 

passing arguments, instead of memory references to stack as VAX uses. For 

example, die argument information may be designated to be in register-25 (R25), 

and R16-R21 used for arguments. Then, if there are more than six arguments to be 

passed, the callin g routine leaves the remainder of the arguments on top of the 

stack Thus, an example of code to set up for a jump to a subroutine for this type 

of machine, assuming there are eight arguments, is as follows: 

LDQ R16,argl . . 

LDQ R17,arg2 



LDQ R21,arg6 
SUBQ SP,#16,SP 
STQ R5.8(SP) 
STQ R6,0(SP) 
JSR R28.R24 

The code translator, according to another feature of one embodiment of the 
invention, resolves this difference in the way argument lists are passed, without 
requiring all argument list references to be modified by hand by the user through 
editing the source code. 
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m ^fler examines d AP-based metn«y references in me input code ,o 
de^howdsesarne-gun^fe^^^^^^T™- 

VAX* in the target RISC architecture, the argument count appears in a defined 
ST* 2 ^on Register ~ * 

first sit arguments are received m registers Rlo-KZi on 

must be taken. For example, if the VAX code is of the form 

MOVL 4(AP)[R0]Ji.l .._„ 
„ tea runtime indexed reference is made, it is necessary to make a afferent 

qua dword register and stack arguments into a longword argument h« - ^ 

A p m es^r M yresuBta^n^=«»^«8^ llst - ,,n5 ' A ^ ^ 
^eZeTwim vaLe indices, or any non-iongword aligned AP offsets. In dns 

VAX code the storage allocator 27 of the compiler generates cod. to copy argu- 

^ IZZ where they have been placed by the original source code, mto 
n.entsftommesractwhe J ^ (reqttiring m ore 

RISC argument regtsmrs. > *ere - " ^ ^ 

man R16-R21), me seventh and beyond must be copies 

„f* e stack. The argument information register R-5 receives me 
bit slots on top of ^ ^3^ ^en at OCFP). Conesponding code to 
argument count, which, on VAA, wouiu « 
dean me srack after me called routine remms is also generated. 
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* - ™««»rfuie used in the storage 
^ phase for mapping "TTlt^ • « - * * — * 

«- 19 °- ■° 4 "rr ^ , - " 1— * <**<** » - a *• "f" 

connol returns via pa* 192- « I94 to see if the argument list has 

hA P . point 193. and if so. checked « ^ „ (meffl mg 

*e timber of longwom*^*" *^ location, so the offset is 

10 «hi*rn^«^ Ug °^^ tere ^R17t.im.andme 

aivided by four » ft *= «rg»mem mdex » *e*P»e ^ „ 

reference is ch-gedm ^-JSII hem 197 the offset is 

— *" *" 'T ry ^hr H h is fid in decision point 194 *. the argument 
c^ged » d« frame pointer. If n is roun change the argument 

list has been homed, then the opeianon m j^^^ m( f sad the offset to die 
pointer AP to a frame pointer FP in the register reference, 
homed list in the frame, to the offset. 

• w been described with reference to specific embodi- 
ments, this descnpnon is M, m " u „ otto em bodiments of the 

^ t tSrefom conned *. - : " 
description, k • thereforecon V _ of ^ ta vennon. 

„ such modifications ^embodiments as fell ««iun 
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1 

22 



23 



1724M4: 3**J 

push! 
1724936 : r»*r*« 

1724196: xa*tr 



•ntry 
•ntry 



(1.1) M*t:l724936, 
■am: TIST 



pC .*:l726016. "Ml! 0 



r0 



24 



25 



1725024 i «y«r«f 

1724976: coadbr 

«ddl3 
1725112: r**r*e 

1725152s 

1725232: r«**«« 

1725192: mmm ft 

1725064: 



rl. r2, 



26 



27 



blss 
1725320: «Y»*«* 

1725272: eoftdbc 

•ovl 
1725440: f*t*t 

1725400: 

17254«0: f*tcb 
1725520: flft 
1725360: iMtr 



ooooooop 



28 



(1 fl ..«t:i724696. P C ^ : tT!!!d 4# 

■•••Ua: , . , as M -M5Si 1 3S 2i " 

Op l: 17240 J« 
l * b «l 21 ».«t:1724»7«. pr.-.17J«»»«. 

Jc.*tl725024. 
fill tagt : I 72511* • v* w * 
IX 'U«I-.: 20. *«0» O..*: •••• 
Op is 1725024 

;,-i:Url7MlS*. 

u fe^r^ sbs.. 

(2.01 ••«tti72*0«4 • , . e0 

wetft: »e«i *■*•«•« 

OD I: 1725232 ,-.•»« t«3 

Op l: 1725112 
Op 2: 1725152 
Op J: 1725192 

l * b (l 21 a«*:l72S272. : 1725064 . 

Op l: 1725320 

US«5 %r" •1725440. 
UCMIi t««* 

OP lI ^I««20. ,r.»- 1725400. 

(9,9) Bttt : 17Z3«« • * 

° P li ± 7 ?»MM pr.*:t725410. 
Op 2: 1725520 

l*b2 



fla?*: 
tl«9«: 



f 1»9« 5 
flifi: 

ci*«» s 

f l«O s 

»•«*: 

«l««o* 
U»« eoott: 1 



€1««»: 
Cl*g*= 



0 

0. 
0 
4 



ei*9«: 
1 

ei«««* 

fl«*«s 

«i«g«* 



o 

2 

0 
0 
0 
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1725600: 

1725500: branch 

2t lotol: Addi2 
1725*00: 

1725712: 

" 1725744: r«ar«« 

1725040: iaot>r 



00000012 3° 



00000015 



l*b2: popl 
1725044: l»b«l 

17250*4: rs^rof 

1725024: ■••ro« 

1725004: tote* 
1725070: f*ft 
1725704: taotr 



11 rlto 
1720010: rob 



..1725500. DC.V.1725300. fl*q«: 

op l; 

(5.01 M «t:l725744. 

Ht«r»l 4 . r .*:i725712. 

»•«• Oo*4: »•»• 
op 1: 1725712 
op 2: 1725744 



Cl«q« : 
Cl*q« : 

ei»9» : 



o 
o 

0 
0 



C5 



( 



.. 9tftii p *»*:l725«40 , 
1,11 ■•«t:l725004, P" 

S -^725024 . 9CM : 1725044 . 

»M«toe; t"l7250«4 . 
Xccttt: coo« 
(9,91 ■•«t:XTl5»^» . 

Osods ••»• 
Op li 1725004 
Op 2: 1?W« 



C10*0 5 

ei*o* 

1 

f l*q* s 

ei«9» : 



o 
o 

2 

0 

0 
0 



<!,!> ••*t:!724004. 



pr^:l725704. s 
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. 1724004 .ad:l723000 



1724004 

1723024 



1720300 
1720240 



i raaraC 



(1.11 ••*t:^2Sa24. 

? C ?t20300. 
U*a2 



prtv:i7200i0 , 

«imo: 4 



Ola«a* * 



Us# coanC 



1720320 
1720200 



: ra*r«0 



172332ft s oy«a« 



1720200 
1723232 



: Miri< 



1723000: «Y« r# * 



Xcctf * : r..d/«it. **«iac 

(1.21 Mlt lt .d! wliftt* 

cl ?! U«"i"2«4.. ,^23232. 
*ee«os: ttft i^ciUt« 



L 

ei**o: 4 

os« couftt : • 
01***: « 



1720321 .M.M- *«••«• «* i72 ° 7< ^ 

i « eh fic.tr <) 



•••••• 



1720040: l*b«t 
1724930s cM*«« 
1724000: iaotr 

1724070: coftdbc 



(0 



MftfilllUH.' 0 



flag*: 20 



0| ««*t:l724030» 
C l ?r:«'"724000. F«-^" 4i ' 

op is 1723024 



CC» u««d: CVHt 



1723112 .nd: 1723272 •• 



1723112: 
1725152: 



(I. 



1725004: ia«tr 



1725272: eoadfai 



„ ...t:172»132 • 

Cl.l> « Et:l "* 2 ,?' . ,.t a« local. 

t,oi 0««d: 1-2. 20 
op is 1723112 
Op 2: 1725132 

OP 3: l7 ?™,„ . r ..sl7230«4. 
11 aftt: 1723430. 
opc.d. : 21, 
ol is 112SJ20 

Q| IRQTITI rn= SHPFT 



as 



Claqs: 20 
Cl«q«: 20 
Claqi: c 



f !•<?«*• 0 



(1 
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initial st»ek 

input .llftlMMI !§-»■ 
wtittta *u«»»tuc«: 
CC» *■* 



op I: 1725400 
op i; 1725*00 



1-725410 : e«tch 
1725520: 
17253*0: iM" 

17235*0: brnaek 

-.-sj .-4sr.u asir— 

2 ittceHio". * . . stack C*n«*o * " 4 
initial Stack W**- 8 " c 

input 

written MfWt*' 11 30 
CCS CV«* 



1725**0 

\ 



fines: 0 
eincs: 20 
fl»C»: 0 

2 

flags: 0 
# nd:l725«40 



1725000: labnl 
1725712: litt«« 
1725744: 
1723040: inntr 



pp«»:l7235«0, 
Dftt;l725il0. 



11.11 ■••ttlMS712. 
■ass: Uk»l 
<5.0» nn«t:1723744. 

ftscs Usad: 30 

m li 1725H2 
Op 2: 1723744 



Cl««o: o 
£1**0 : 0 
flags: 4 



fl**o: 



input 5 "l* 

Writtun u««i«tut»: 5 
CC* u«u«: u«* 



172S»44: UMl 
I1JJM4: tmteh 
l72S*7«t eu«ru« 
1725714 : iu«tr 



D c«*:l72S«40 . 
pcu«'- 172S»44 . 



I72C01C: *■•» 



11.11 au«t:l72S»©4. 

tt.ti »u«tsna»»2*' 

°» IS !!!!! M. pr.u l72S.04. 

**;. pr.u-1729f7«. 



11**0: 0 

fiacs: 0 

flags: 0 

2 

flags: 0 
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7 
8 
9 
10 
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12 
13 
14 
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WHAT IS CLAIMED IS: 



means for generating a now g«fm » , , „,„ 

H JTU represents .single egression in said code. and where 
branch or return with no intermediate exit or entry. 

cm. in - •* *» "* '*-» ° f 7"^of W ocks 

means respond . said porting fer repomng to a e» «he » of blodcs 

having potentially improper stack references. 

" ■ Mh.. to claim 1 mctading means for recording for each block that 
1 AuDaratus according to ciaim i, uiuau— ... . j 
*■ ' . i_ tracine through each block of said 

flow graph checking each block before enrenng to see tf the Mock 

of s^ck. reporting a difference in the conren, of recorded total depth of the sreck 
.or a corren, Mock and a successor block which has ahead, been vt^red. 
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1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 



15 
16 



1 
2 
3 
4 

1 
2 
3 



4 . A memod of compUing input code wrmnn *r . ft. mactane 
produce objecr coa^ for a differ nucnine ..hkeenne. wherein sam firs, 
LbheJ use, . suck referenced by an argument suck poimer. compn»ng the sups 

generating a flow graph in an intermedia* language from said input code by a 
convener, tbe flow grapb being competed of blocks, end the blocks being composed 
of tuples, where each tuple represents a sing!e expression in said input code^nd 
J2 each block represents a sequence of one or more tuples- begmnmg wtm an entr> 
aodendmgmabranchorremmwtmnomuttned^ .. 

racing through each block of said flow graph » detect tuples whtch have me 
eefec of modifying me stack p*nu, «* memdmg ft, «ch Hock *• 
*. stack pomur by mples of said block which have me effect of modtfym, the suck 
^nu, Z recording me net change m me torn, depm of the suck from the begmmng 



14 of sold tracing; and 

reporting to a user the identity of blocks having potentially improper stack 



references. 



1 

2 routines 



L block has been vished in said nacing. and in tueing through each b,ock of sard 
flow guph checking each b.ock before enuring . see if the block has been vtstted. 
end, if so, going to another p«h mmer man visiting said block agam. 

« A memod according » claim 5 including me «ep of. upon computing said step of 
Jig. repotting me a difference in the - of recorded total depm of me suck 
for a current Hock and a successor block which has ato-ly been vistted. 

,. A memod according to cUim 6 wherein said code includes a piuraUty of caUable 
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1 8. A method according to claim 4 wherein each said block begins with an entry and 

2 ends in a branch or return with no intermediate entry. 

1 9. Apparatus for processing computer code in a compiler or code translator, 

2 comprising: 

3 means for generating a flow graph in an intermediate language from said code. 

4 the flow graph being composed of blocks, and the blocks being composed of tuples. 

5 where each tuple represents a single expression in said code, and where each block 

6 represents a sequence of one or more tuples; 

7 means for tracing through each block of said flow graph to detect reference to 
g registers and to create an output-register set, and in each said block: 

means for recording identity of a register in an input-register set for this 
block if a register reference is a read from a register not yet written to in the current 

11 block. 

12 means for removing identity of a register from the output-register set if 

13 a register reference is a read from a register already written to in the current block. 

14 means for adding identity of a register to the output-register set if a 

15 register reference is a write to a register. 



9 
10 



16 



18 



means for recording identity of a register in a written-register set for 



!7 this block if a register reference is a write to a register. 



means for passing said output-register set to the succeeding block. 



1 10. Appararnsaccordmgtodaim^^ 

2 of said flow graph in a reverse direction, and for each said block passing the input- 

3 register set to a predecessor block, and in each predecessor block updating the input- 

4 register set to include registers in the input-register set passed to this predecessor block 

5 bv a successor block and not in the written-register set for this predecessor block. 
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1 
2 
3 
4 

5 direction. 



17 
18 
19 



„ Apparatus wording ,. claim 9M— ** » 8 *° 

, i™, « for said code upon completing said tracing for all of 

content of said output-register set for saw cone p» r 

said blocs. u» means fcr said inpm-reg*«r set far s-d code and rep«m* ^ 

^.register set for said code upon competing said *ep of .racing » the reverse 



1 

2 
3 
4 
5 

6 
7 

8 

9 

10 . • 
11 
12 

13 
14 

15 

16 register set 



j fnr a first machine architecture to 

12. A method of compiling input code written for a first mac 

•' ■ *■ a A;ff~rmt machine architecture, comprising the steps 

produce object code for a second different nxacrune arcxu 

convex, me How graph being Omposed of blocks. and me bloc* ^J™**°* 
of tuples, whet, each tuple represems a single «pmssion in said input code and 
UL e~h block represents a sequence of one or more ruples beginning with an entry 
oi'iu BudixiE in a branch or return with no intermediate entry; 

.^g through each block of said flow graph .0 detect reference to registers 

and ro create an outpm-register set. and in each said block: _ _ 

i, a regis^r reference U a read from a regis- no, vet wnnen m m me 

ct^en. block, recording such regismr in an mpu,-reg*ter se, for this block^ 

a .. agister reference is a read from a register .heady wrmen to » me 
current block, removing such mgismr ftom me o«pu,-reg*er set. 

if a register reference is a write, adding such register to the output 

passing said outpm-regtaer se. to me succeeding block, 
upon completing said step of tracing for all of said blocks, reporting 
contem of said output-register set for said code. 

• wherein said output-register set is recorded in 

13. A method according to claim 12 wnerein r 



1 

2 each block 
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1 
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14 A method according to claim 12 wherein said input code contains one or m °' e 
rointoe s. and the content of s*d ousput-registe, set is reponed re me user fox «ch serf 



routine. 



15. A method according to claim 12 wherein said srep of rracmg includes, if a^ 
regisrer reference is a write re a register, recording such regismr in a wrmen-regtsrer 
set for this block. \ 

U A memod according re claim 12 including me step of. upon completing said step 
of rraemg. reporting *. eonren, of said omput-regismr set for said cod., report** satd 
inpm-regisrer aer for aaid code, and reporting said wnnen-regisier set for sard code. 
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5 comprising: 
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14 argument, 



17 Apparamsfor rranslating compurer code wrinen for a firs, rnachine arcltirecmre to 
code for a second machine archhecmre. wherein said first arcurrecmre uses a sreek 

S aid second rnachme archhecmre uses regrsrers to pass arguments m procedure calls. 

for generating a flow graph in an inrermediare language from said code. 
*. flow graph being composed of bloc*, and me bloc* heing composed of mp^s, 
where e«h tuple represents a single expression in said code, ' 
represents e sequence of one or more mples beginning with an entry and endmg m a 
branch or return with no intermediate entry; 

^aos for nacmg said flow graph re find a ruple corresponding re a memory 
reference defined by said argumenr poinrer and an ofe« re an argument 

for converting said offset re an index giving me number of sard 
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for converting said memory reference re a regisrer reference; 
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means for compiling using said flow graph to produce object code for said 
second machine architecture. 

t ,* ^^m said stack may be of any size and said 
18 Apparatus according to claim 17 wherem said stac* 

number of registers to pass arguments is a toed number. 

^ m feed number. *en iot m ^P™^- 

generating a stack frame referent by * frame poorer to pass an argume rep 

ed by said offset- 

20 Appamms according to cUim !9 meiuding d« of genemrir* a fl^ «*» 
20. Appara«* _ sa id frame pointer and said 

from said offset and generating a memory reference using saia t~ 



zauxt offset. 



21 Amedrod of transit computer code wrinen for a flrs, machine arch^e^ » 
L fox a second n-cbine amhfcecmse. wherein said firs, archimemre uses a s^ 

saio second machine amhneerure uses registers to pass argument » procedure 
^ Lm composed of Weeks. and the blocks being composed of nuermedtate- 

cnn— — — • 

JTL each block represents a sequence of one or more elements. 

1^1 floTgmpb ,o flnd a eiemeut corresponding ,e a memory reference 
defined by said argument pointer and an offset 10 an argument. 

IL*. - » - *d« giving *e number of said „gumem. 
converting sud memory reference ,o a segister reference; 
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14 compiling using said flow gmph ,o pmduee object code for said secand 

^2 machine architecture, 

j 22. Am ethod according to claim 21 wherein said stack may be of any size and said 

number of registers to pass arguments is a fixed number. 



1 



23. A method according to claim 22 wherein, if the number of arguments 
^ said fixed number, men for an offset representing grester rhan satd fl«d rmmc« 
geBcmiBe a stack frame referenced by a frame pointer » p=s an argument repmsem- 



1 

2 
3 

4 ed by said offset. 



24 A memc4aecordmg reclaim 23 mdud^ 

^ said offset and generating a memory reference using said frame poimer and sard 
frame offset. 

25. A method according to claim 21 wherein each of said blocks begins with an enrry 
and ends in a branch or return with no intermediate entry. 

26. A method according to claim 21 wherein said elements are tuples. 

27. Apparatus for processing computer code in a compiler or code translator, eompris- 
**■ means for generating a flow gmphm an hnermediae langu^e from said code. 

w hem each ruple repmsen* a single egression in said code, and where ea* ^ 

r «. moles beginning with an entry and ending in a 
icpresents a sequence of one or more tuples oegmuu s 

branch or rcrum with no intermediate exit or entry; 
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means for tracing in a reverse direction through each block of said flow graph 
to detect any tuples which read or set condition codes, 

means for generating from detected tuples which read condition codes a 
required set of condition codes stored with the block, 

means for updating said required set for tuples setting said condition codes. 

28. Apparatus according to claim 27, wherein said condition codes include overflow, 
equal to zero, negative and carry. 

29. Apparatus according to claim 28 wherein said means for updating said required 
set for tuples setting said condition codes includes means for resetting bits in said 

3 required set which have previously been set. 

30. A method of compiling input code written for a first machine architecture to 
produce object code for a different machine architecture, said first machine architec- 
ture including condition codes in arithmetic and logic operation, said different machine 
architecture not including condition codes, comprising the steps of: 

generating a flow graph in an intermediate language from said input code by a 
convener, the flow graph being composed of blocks, and the blocks being composed 
of tuples, where each tuple represents a single expression in said input code, and 
g - where each block represents a sequence of one or more tuples; 

tracing through each block of said flow graph in a reverse direction to detect 
any tuples which read or set condition codes, 

generating from detected tuples which read condition codes a required set of 

condition codes stored with the block, 

updating said required set for tuples setting said condition codes, and 
generating operations in said object code using said required set for each block 
to simulate setting and reading the condition codes in said required set. 
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. 31 A ^thod according to claim 30 including the step of. upon calling the predeces- 

2 sor block for a given block, passing said required set of said given block to sari 

v predecessor block, and thereafter ^ , 

' if said predecessor block is encomesed in ano«t>« baclcward flow pa*, and .be 

^pixed ser is a subset of said required s« passed ro said predecessor block, .hen 
omining visrdng said predecessor Mock again, or 

if said required set passed ,o said predecessor block does not include a 
c^dMon code of a required m of a block in said anodter backward flow pa«b, .hen 
9 visiting said predecessor block again. 

3 , A method according to claim 30 wherein said step of tracing includes tracing all 
paths from the end of said code to the beginnmg of said code even if sonoe blocks are 
visited more than once in said tracing. 

33 A method according to claim 32 wherein said step of updating said required set 
for tuples setting said condition codes includes resetting bits in said required set whrch 

3 have previously been set. 

34 A method according to claim 33 wherein said step of tracing includes the step of 
detecting anv tuples for Jump-to-subroutine instructions where the required set « not 
empty, and reporting such occurrence as a possible error in said input code. 

35 A method according to claim 30 wherein said first machine architecture is a CISC 
: architecture and said different machine architecturc is a RISC arcMtecture. 

! 36. A method according to claim 30 wherein said input code includes a plurality of. 
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